Micron Document
____ _ _ _ _
| _ \ ___ | |_ (_) _ __ ___ __| | (_) __ _
| |_) | / _ \ | __| | | | '_ \ / _ \ / _| | | | / _ |
| _ < | __/ | |_ | | | |_) | | __/ | (_| | | | | (_| |
|_| \_\ \___| \__| |_| | .__/ \___| \__,_| |_| \__,_|
|_|


The NomadNet German Wikipedia | Archives | Info
- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b

🔍 Search

ÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻ

Grafikpipeline
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
top
Eine Computergrafik-Pipeline, auch Rendering-Pipeline oder einfach Grafikpipeline, ist eine Modellvorstellung in der Computergrafik, die beschreibt, welche Schritte ein Grafiksystem zum Rendern, also zur Darstellung einer 3D-Szene auf einem Bildschirm, durchfĂŒhren muss. Da diese Schritte sowohl von der Soft- und Hardware als auch von den gewĂŒnschten Darstellungseigenschaften abhĂ€ngen, gibt es keine allgemein gĂŒltige Grafikpipeline. Zur Ansteuerung von Grafikpipelines werden ĂŒblicherweise Grafik-APIs wie Direct3D oder OpenGL verwendet, die die zugrundeliegende Hardware abstrahieren und dem Programmierer viele Aufgaben abnehmen.

Die Darstellung dreidimensionaler Welten am Computer ist heute weit verbreitet und Teil sehr vieler Computerspiele. Das sogenannte Rendering erzeugt dabei aus abstrakten Daten Grafiken.

Das Modell der Grafikpipeline findet ĂŒblicherweise beim Echtzeitrendern Anwendung. Oft sind hier die meisten Schritte der Pipeline in Hardware implementiert, was besondere Optimierungen ermöglicht. Die Bezeichnung „Pipeline“ wird in einem Ă€hnlichen Sinn wie die Pipeline bei Prozessoren verwendet: Die einzelnen Schritte der Pipeline laufen zwar parallel ab, sind jedoch solange blockiert, bis der langsamste Schritt beendet wurde.

Contents

‱ Aufbau
‱ Anwendung
‱ Geometrie
‱ Rasterung
‱ Inverse
‱ Shader
‱ Literatur

──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Aufbau

Eine Grafikpipeline lĂ€sst sich in drei große Schritte aufteilen: Anwendung, Geometrie und Rasterung.cite-ref-1[1]

Anwendung

Der Anwendungsschritt wird von der Software ausgefĂŒhrt, er lĂ€sst sich daher nicht in pipelineartig ausgefĂŒhrte Einzelschritte aufteilen. Es ist jedoch möglich, ihn auf Mehrkernprozessoren oder Mehrprozessorsystemen zu parallelisieren. Im Anwendungsschritt werden Änderungen an der Szene vorgenommen, wie sie zum Beispiel aufgrund der Benutzerinteraktion mittels EingabegerĂ€ten oder bei einer Animation nötig sind. Die neue Szene mit allen ihren Primitiven – meist Dreiecke, Linien und Punkte – wird dann an den nĂ€chsten Schritt der Pipeline weitergeleitet.

Beispiele fĂŒr Aufgaben, die typischerweise vom Anwendungsschritt ĂŒbernommen werden, sind Kollisionserkennung, Animation, Morphing und die Datenverwaltung. Zu letzterer gehören etwa Beschleunigungstechniken mittels rĂ€umlicher Unterteilungsschemata (Quadtree, Octree), mit denen die aktuell im Speicher gehaltenen Daten optimiert werden. Die „Welt“ und ihre Texturen eines heutigen Computerspiels sind sehr viel grĂ¶ĂŸer als auf einmal in den verfĂŒgbaren Arbeitsspeicher oder Grafikspeicher geladen werden könnte.

Geometrie

Der Geometrieschritt, der fĂŒr den Großteil der Operationen mit Polygonen und deren Eckpunkten (Vertices) verantwortlich ist, lĂ€sst sich in folgende fĂŒnf Aufgaben unterteilen. Es hĂ€ngt von der jeweiligen Implementierung ab, wie diese Aufgaben als tatsĂ€chliche, parallel ausgefĂŒhrte Pipeline-Schritte organisiert werden.

Definitionen

Ein Vertex (Mehrzahl: Vertices) ist ein Punkt in der Welt. Diese Punkte dienen dazu, die FlÀchen zu verbinden. In speziellen FÀllen werden auch direkt Punktwolken gezeichnet, dies ist aber noch die Ausnahme.

Ein Dreieck (englisch: Triangle) ist das am hĂ€ufigsten vorkommende geometrische Primitiv der Computergrafik. Es wird durch seine drei Ecken und einen Normalvektor definiert – letzterer dient dazu, die Vorderseite des Dreiecks anzugeben und ist ein Vektor, der senkrecht auf der FlĂ€che steht. Ein solches Dreieck kann mit einer Farbe versehen sein oder mit einer Textur.

Das Weltkoordinatensystem

Das Weltkoordinatensystem ist das Koordinatensystem, in dem die virtuelle Welt angelegt wird. Dieses sollte, damit die nachfolgende Mathematik einfach anwendbar ist, einige Bedingungen erfĂŒllen: Es muss sich um ein rechtwinkliges kartesisches Koordinatensystem handeln, bei dem alle Achsen gleich skaliert sind. Wie die Einheit des Koordinatensystems festgelegt wird, ist hingegen dem Entwickler ĂŒberlassen. Ob also der Einheitsvektor des Systems in Wirklichkeit einem Meter oder einem Ångström entsprechen soll, ist vom Anwendungsfall abhĂ€ngig. Ob ein rechtshĂ€ndiges oder ein LinkshĂ€ndiges Koordinatensystem verwendet werden soll, kann durch die zu verwendende Grafikbibliothek vorgegeben sein.

Beispiel: Wenn wir einen Flugsimulator entwickeln wollen, können wir das Weltkoordinatensystem so wĂ€hlen, dass der Ursprung in der Mitte der Erde liegt und die Einheit auf einen Meter festlegen. ZusĂ€tzlich definieren wir – damit der Bezug zur RealitĂ€t einfacher wird – dass die x-Achse den Äquator auf dem Nullmeridian schneiden soll und die z-Achse durch die Pole verlĂ€uft. In einem Rechtssystem lĂ€uft damit die y-Achse durch den 90°-Ost-Meridian (irgendwo im Indischen Ozean). Jetzt haben wir ein Koordinatensystem, das jeden Punkt auf der Erde in kartesischen Koordinaten beschreibt. In diesem Koordinatensystem modellieren wir nun die GrundzĂŒge unserer Welt, also Berge, TĂ€ler und GewĂ€sser.
Anmerkung: Außerhalb der Computergeometrie verwendet man fĂŒr die Erde geografische Koordinaten, also LĂ€ngen- und Breitengrade, sowie Höhen ĂŒber dem Meeresspiegel. Die nĂ€herungsweise Umrechnung – wenn man davon absieht, dass die Erde keine exakte Kugel ist – ist einfach:
( x y z ) = ( ( R + h a s l ) ⋅ ⋅ cos ⁡ ⁡ ( l a t ) ⋅ ⋅ cos ⁡ ⁡ ( l o n g ) ( R + h a s l ) ⋅ ⋅ cos ⁡ ⁡ ( l a t ) ⋅ ⋅ sin ⁡ ⁡ ( l o n g ) ( R + h a s l ) ⋅ ⋅ sin ⁡ ⁡ ( l a t ) ) {\displaystyle {\begin{pmatrix}x\\y\\z\end{pmatrix}}={\begin{pmatrix}(R+\mathrm {hasl} )\cdot \cos(\mathrm {lat} )\cdot \cos(\mathrm {long} )\\(R+\mathrm {hasl} )\cdot \cos(\mathrm {lat} )\cdot \sin(\mathrm {long} )\\(R+\mathrm {hasl} )\cdot \sin(\mathrm {lat} )\end{pmatrix}}}

mit R {\displaystyle \;R} = Erdradius = 6.378.137 m, h a s l {\displaystyle \ \mathrm {hasl} } = Höhe ĂŒber Meer, l a t {\displaystyle \ \mathrm {lat} } = Breitengrad, l o n g {\displaystyle \ \mathrm {long} } = LĂ€ngengrad.

SĂ€mtliche der folgenden Beispiele gelten in einem Rechtssystem. FĂŒr ein Linkssystem mĂŒssen eventuell Vorzeichen vertauscht werden.

Die in der Szene angegebenen Objekte (HĂ€user, BĂ€ume, Autos) sind aus GrĂŒnden der einfacheren Modellierung oftmals in ihrem eigenen Objektkoordinatensystem (auch Modellkoordinatensystem oder lokales Koordinatensystem) angegeben. Um diesen Objekten Koordinaten im Weltkoordinatensystem oder globalen Koordinatensystem der gesamten Szene zuzuweisen, werden die Objektkoordinaten mittels Translation, Rotation oder Skalierung transformiert. Dies geschieht durch Multiplikationen der entsprechenden Transformationsmatrizen. Außerdem können aus einem Objekt mehrere unterschiedlich transformierte Kopien gebildet werden, etwa ein Wald aus einem Baum; diese Technik wird Instancing genannt.

Um ein Modell von einem Flugzeug in der Welt zu platzieren, bestimmen wir zunĂ€chst mal vier Matrizen. Da wir im dreidimensionalen Raum arbeiten, sind die homogenen Matrizen, die wir fĂŒr unsere Berechnung brauchen, vierdimensional. Als erstes brauchen wir drei Rotationsmatrizen, nĂ€mlich fĂŒr jede der drei Flugzeugachsen (Hochachse, Querachse, LĂ€ngsachse) eine.
Um die x-Achse (im Objektkoordinatensystem meist als LĂ€ngsachse definiert) R x = ( 1 0 0 0 0 cos ⁥ ⁥ α α sin ⁥ ⁥ α α 0 0 − − sin ⁥ ⁥ α α cos ⁥ ⁥ α α 0 0 0 0 1 ) {\displaystyle R_{x}={\begin{pmatrix}1&0&0&0\\0&\cos \alpha &\sin \alpha &0\\0&-\sin \alpha &\cos \alpha &0\\0&0&0&1\end{pmatrix}}}
Um die y-Achse (im Objektkoordinatensystem meist als Querachse definiert) R y = ( cos ⁥ ⁥ α α 0 − − sin ⁥ ⁥ α α 0 0 1 0 0 sin ⁥ ⁥ α α 0 cos ⁥ ⁥ α α 0 0 0 0 1 ) {\displaystyle R_{y}={\begin{pmatrix}\cos \alpha &0&-\sin \alpha &0\\0&1&0&0\\\sin \alpha &0&\cos \alpha &0\\0&0&0&1\end{pmatrix}}}
Um die z-Achse (im Objektkoordinatensystem meist als Hochachse definiert) R z = ( cos ⁥ ⁥ α α sin ⁥ ⁥ α α 0 0 − − sin ⁥ ⁥ α α cos ⁥ ⁥ α α 0 0 0 0 1 0 0 0 0 1 ) {\displaystyle R_{z}={\begin{pmatrix}\cos \alpha &\sin \alpha &0&0\\-\sin \alpha &\cos \alpha &0&0\\0&0&1&0\\0&0&0&1\end{pmatrix}}}
Zudem wenden wir eine Translationsmatrix an, die das Flugzeug an den gewĂŒnschten Punkt in unserer Welt verschiebt: T x , y , z = ( 1 0 0 0 0 1 0 0 0 0 1 0 x y z 1 ) {\displaystyle T_{x,y,z}={\begin{pmatrix}1&0&0&0\\0&1&0&0\\0&0&1&0\\x&y&z&1\end{pmatrix}}} .
Anmerkung: Obige Matrizen sind gegenĂŒber denjenigen im Artikel Drehmatrix transponiert. Die ErklĂ€rung dazu steht im folgenden Abschnitt.

Nun könnten wir die Position der Vertices des Flugzeugs in Weltkoordinaten berechnen, indem wir jeden Punkt nacheinander mit diesen vier Matrizen multiplizieren. Da die Multiplikation einer Matrix mit einem Vektor recht aufwendig ist, geht man meistens einen anderen Weg und multipliziert zunĂ€chst die vier Matrizen zusammen. Die Multiplikation zweier Matrizen ist zwar noch teurer, muss aber nur einmal fĂŒr das ganze Objekt ausgefĂŒhrt werden. Die Multiplikationen ( ( ( ( v ∘ ∘ R x ) ∘ ∘ R y ) ∘ ∘ R z ) ∘ ∘ T ) {\displaystyle ((((v\circ \!R_{x})\!\circ \!R_{y})\!\circ \!R_{z})\!\circ \!T)} und ( v ∘ ∘ ( ( ( R x ∘ ∘ R y ) ∘ ∘ R z ) ∘ ∘ T ) ) {\displaystyle (v\circ \!(((R_{x}\!\circ \!R_{y})\!\circ \!R_{z})\!\circ \!T))} sind gleichwertig. Danach könnte die resultierende Matrix auf die Punkte angewendet werden. In der Praxis wird die Multiplikation mit den Punkten allerdings jetzt immer noch nicht angewendet, sondern zuerst die Kameramatrizen – siehe unten – bestimmt.

FĂŒr unser Beispiel von oben muss die Translation allerdings etwas anders bestimmt werden, da die Bedeutung von „Oben“ – außer am Nordpol – nicht mit der positiven z-Achse ĂŒbereinstimmt und daher das Modell auch noch um den Erdmittelpunkt gedreht werden muss. T K u g e l = T x , y , z ( 0 , 0 , R + h a s l ) ∘ ∘ R y ( π π 2 − − l a t ) ∘ ∘ R z ( l o n g ) {\displaystyle T_{\mathrm {Kugel} }=T_{x,y,z}(0,\ 0,\ R+\mathrm {hasl} )\circ R_{y}\left({\tfrac {\pi }{2}}-\mathrm {lat} \right)\circ R_{z}(\mathrm {long} )}

Der erste Schritt schiebt den Ursprung des Modells in die richtige Höhe ĂŒber der ErdoberflĂ€che, danach wird um LĂ€nge und Breite rotiert.

Die Reihenfolge, in der die Matrizen angewendet werden, ist wichtig, denn die Matrizenmultiplikation ist nicht kommutativ. Das gilt auch fĂŒr die drei Rotationen, wie man sich an einem Beispiel vor Augen fĂŒhren kann: Der Punkt (1, 0, 0) liegt auf der x-Achse, wenn man den zunĂ€chst um jeweils 90° um die x- und dann um die y-Achse rotiert, landet er auf der z-Achse (die Rotation um die x-Achse hat keinen Effekt auf einen Punkt der auf der Achse liegt). Rotiert man hingegen zunĂ€chst um die y- und dann um die x-Achse liegt der resultierende Punkt auf der y-Achse. Die Reihenfolge an sich ist beliebig, solange man sie immer gleichmacht. Die Reihenfolge mit x, dann y, dann z (Roll, Pitch, Heading) ist hĂ€ufig am intuitivsten, denn die Rotation bewirkt u. a., dass die Kompassrichtung mit der Richtung der „Nase“ ĂŒbereinstimmt.

Es gibt außerdem zwei Konventionen, diese Matrizen zu definieren, und zwar abhĂ€ngig davon, ob man mit Spaltenvektoren oder mit Zeilenvektoren arbeiten will. Verschiedene Grafikbibliotheken haben hier unterschiedliche PrĂ€ferenzen. OpenGL beispielsweise bevorzugt Spaltenvektoren, DirectX Zeilenvektoren. Aus der Entscheidung folgt, von welcher Seite die Punktvektoren an die Transformationsmatrizen multipliziert werden. FĂŒr Spaltenvektoren erfolgt die Multiplikation von rechts, also v o u t = M ∘ ∘ v i n {\displaystyle v_{\mathrm {out} }=M\!\circ v_{\mathrm {in} }} , wobei v o u t {\displaystyle v_{\mathrm {out} }} und v i n {\displaystyle v_{\mathrm {in} }} 4 × 1-Spaltenvektoren darstellen. Auch die Konkatenierung der Matrizen erfolgt von rechts nach links, also beispielsweise M = T x ∘ ∘ R x {\displaystyle M=T_{x}\!\circ R_{x}} , wenn zuerst rotiert und dann verschoben werden soll. Bei Zeilenvektoren verhĂ€lt es sich genau umgekehrt. Die Multiplikation erfolgt jetzt von links als v o u t = v i n ∘ ∘ M {\displaystyle v_{\mathrm {out} }=v_{\mathrm {in} }\!\circ \!M} mit 1 × 4-Vektoren und die Konkatenierung lautet M = R x ∘ ∘ T x {\displaystyle M=R_{x}\!\circ T_{x}} wenn ebenfalls zunĂ€chst rotiert und dann verschoben wird. Die weiter oben dargestellten Matrizen gelten fĂŒr den zweiten Fall, diejenigen fĂŒr Spaltenvektoren ergeben sich als Transponierte davon. Es gilt die Regel ( v ∘ ∘ M ) T = M T ∘ ∘ v T {\displaystyle (v\circ \!M)^{T}=M^{T}\!\circ v^{T}} ,cite-ref-2[2] was fĂŒr die Multiplikation mit Vektoren bedeutet, dass man durch die Transponierung die Multiplikationsreihenfolge vertauschen darf.

Das Interessante an dieser Matrixverkettung ist nun, dass durch jede solche Transformation ein neues Koordinatensystem definiert wird. Das lĂ€sst sich beliebig weiterziehen. So kann beispielsweise der Propeller des Flugzeuges als eigenes Modell vorliegen, das dann durch eine Translation an die Flugzeugnase platziert wird. Diese Translation muss nur noch die Verschiebung vom Modellkoordinatensystem ins Propellerkoordinatensystem beschreiben. Zum Zeichnen des gesamten Flugzeugs wird also zuerst die Transformationsmatrix fĂŒr das Flugzeug bestimmt, die Punkte transformiert und dann anschließend die Translation zum Propellermodell auf die Matrix des Flugzeugs multipliziert und dann die Propellerpunkte transformiert.

Die auf diese Art berechnete Matrix nennt man auch die Welt-Matrix (englisch: World-Transformation). Sie muss fĂŒr jedes Objekt der Welt vor der Darstellung bestimmt werden. Die Anwendung kann hier auf VerĂ€nderungen Einfluss nehmen, also beispielsweise die Position unseres Flugzeuges entsprechend der Geschwindigkeit Ă€ndern.

Kameratransformation

Neben den Objekten definiert die Szene auch eine virtuelle Kamera oder einen Betrachter, der die Position und Blickrichtung angibt, aus der die Szene gerendert werden soll. Um die spÀtere Projektion und das Clipping zu vereinfachen, wird die Szene so transformiert, dass sich die Kamera am Ursprung befindet, mit Blickrichtung entlang der Z-Achse. Das resultierende Koordinatensystem wird Kamera-Koordinatensystem genannt und die Transformation Kameratransformation (englisch View-Transformation).

Die View-Matrix wird ĂŒblicherweise aus Kameraposition, Zielpunkt (wohin schaut die Kamera) und einem Up-Vektor („Oben“ aus Sicht des Betrachters) bestimmt. Zuerst werden drei Hilfsvektoren benötigt:
zaxis = normal(cameraPosition - cameraTarget)
xaxis = normal(cross(cameraUpVector, zaxis))
yaxis = cross(zaxis, xaxis)
Mit normal(v) = Normalisierung des Vektors v; cross(v1, v2) = Kreuzprodukt von v1 und v2.
Schließlich die Matrix: ( x a x i s x y a x i s x z a x i s x 0 x a x i s y y a x i s y z a x i s y 0 x a x i s z y a x i s z z a x i s z 0 − − x a x i s ⋅ ⋅ c a m e r a P o s i t i o n − − y a x i s ⋅ ⋅ c a m e r a P o s i t i o n − − z a x i s ⋅ ⋅ c a m e r a P o s i t i o n 1 ) {\displaystyle {\begin{pmatrix}\mathrm {xaxis} _{x}&\mathrm {yaxis} _{x}&\mathrm {zaxis} _{x}&0\\\mathrm {xaxis} _{y}&\mathrm {yaxis} _{y}&\mathrm {zaxis} _{y}&0\\\mathrm {xaxis} _{z}&\mathrm {yaxis} _{z}&\mathrm {zaxis} _{z}&0\\-\mathrm {xaxis} {\boldsymbol {\,\cdot \,}}\mathrm {cameraPosition} &-\mathrm {yaxis} {\boldsymbol {\,\cdot \,}}\mathrm {cameraPosition} &-\mathrm {zaxis} {\boldsymbol {\,\cdot \,}}\mathrm {cameraPosition} &1\end{pmatrix}}}
v 1 ⋅ ⋅ v 2 {\displaystyle \mathrm {v1} {\boldsymbol {\,\cdot \,}}\mathrm {v2} } = Skalarprodukt von v1 und v2.

Projektion

Der Projektionsschritt transformiert das Sichtvolumen in einen WĂŒrfel mit den Eckpunktkoordinaten (−1, −1, −1) und (1, 1, 1); gelegentlich werden auch andere Zielvolumen verwendet. Dieser Schritt wird Projektion genannt, obwohl er ein Volumen in ein anderes Volumen transformiert, da die resultierenden Z-Koordinaten nicht im Bild gespeichert werden, sondern lediglich beim Z-Buffering im spĂ€teren Rasterungsschritt Anwendung finden. Bei einer perspektivischen Abbildung wird eine Zentralprojektion verwendet. Um die Anzahl der dargestellten Objekte zu begrenzen, werden zwei zusĂ€tzliche Clipping Planes verwendet; das Sichtvolumen ist hier also ein Pyramidenstumpf (Frustum). Die Parallel- oder Orthogonalprojektion wird beispielsweise fĂŒr technische Darstellungen verwendet, denn sie hat den Vorteil, dass alle Parallelen im Objektraum auch im Bildraum parallel sind und FlĂ€chen und Volumina unabhĂ€ngig von der Distanz zum Betrachter gleich groß sind. Landkarten verwenden beispielsweise auch eine Orthogonalprojektion (sogenanntes Orthofoto), SchrĂ€gbilder einer Landschaft sind so allerdings nicht zu gebrauchen denn – obwohl technisch natĂŒrlich darstellbar – erscheinen sie uns so verzerrt, dass wir damit nichts anfangen können.

Die Formel zur Berechnung einer perspektivischen Abbildungsmatrix ist: ( w 0 0 0 0 h 0 0 0 0 f a r / ( n e a r − − f a r ) − − 1 0 0 ( n e a r ∗ ∗ f a r ) / ( n e a r − − f a r ) 0 ) {\displaystyle {\begin{pmatrix}w&0&0&0\\0&h&0&0\\0&0&{far}/({near-far})&-1\\0&0&({near}*{far})/({near}-{far})&0\end{pmatrix}}}
Mit h=cot(fieldOfView/2.0) (Öffnungswinkel der Kamera); w=h/aspectRatio (SeitenverhĂ€ltnis des Zielbildes); near=Kleinste Distanz, die sichtbar sein soll; far=Weiteste Distanz, die sichtbar sein soll.

Die GrĂŒnde, weshalb die kleinste und die grĂ¶ĂŸte Distanz hier angegeben werden mĂŒssen, sind zum einen, dass durch diese Distanz dividiert wird, um die GrĂ¶ĂŸenskalierung zu erreichen (weiter entfernte Objekte werden in einer perspektivischen Abbildung kleiner als nahe Objekte) und zum anderen, dass damit die Z-Werte auf den Bereich 0..1 skaliert werden, womit dann der Z-Buffer gefĂŒllt wird. Dieser hat oft nur eine Auflösung von 16 Bit, weshalb die Nah- und Fernwerte mit Bedacht gewĂ€hlt werden sollten. Eine zu große Differenz zwischen dem nahen und dem fernen Wert fĂŒhrt wegen der geringen Auflösung des Z-Puffers zu sogenanntem Z-Fighting. Aus der Formel ist auch ersichtlich, dass der Nahwert nicht 0 sein kann, denn dieser Punkt ist der Fokuspunkt der Projektion. In diesem Punkt gibt es kein Bild.

Der VollstĂ€ndigkeit halber noch die Formel fĂŒr die Parallelprojektion (Orthogonale Projektion): ( 2.0 / w 0 0 0 0 2.0 / h 0 0 0 0 1.0 / ( n e a r − − f a r ) − − 1 0 0 n e a r / ( n e a r − − f a r ) 0 ) {\displaystyle {\begin{pmatrix}2.0/w&0&0&0\\0&2.0/h&0&0\\0&0&1.0/({near-far})&-1\\0&0&{near}/({near}-{far})&0\end{pmatrix}}}
Mit w=Breite des ZielwĂŒrfels (Dimension in Einheiten des Weltkoordinatensystems); h=w/aspectRatio (SeitenverhĂ€ltnis des Zielbildes); near=Kleinste Distanz, die sichtbar sein soll; far=Weiteste Distanz, die sichtbar sein soll.

Aus EffizienzgrĂŒnden werden die Kamera- und die Projektionsmatrix ĂŒblicherweise in eine Transformationsmatrix zusammengefasst, sodass das Kamerakoordinatensystem ĂŒbergangen wird. Die resultierende Matrix ist ĂŒblicherweise fĂŒr ein einzelnes Bild gleichbleibend, wĂ€hrend die Weltmatrix fĂŒr jedes Objekt anders aussieht. In der Praxis werden daher View- und Projection vorberechnet, so dass wĂ€hrend der Darstellung nur noch die World-Matrix angepasst werden muss. Es sind jedoch weitere, aufwĂ€ndigere Transformationen wie Vertex Blending möglich. Frei programmierbare Geometrie-Shader, die die Geometrie verĂ€ndern, können ebenfalls ausgefĂŒhrt werden. Im eigentlichen Renderschritt wird dann Weltmatrix*Kameramatrix*Projektionsmatrix gerechnet und diese dann endlich auf jeden einzelnen Punkt angewendet. Damit werden die Punkte aller Objekte direkt ins Bildschirmkoordinatensystem ĂŒberfĂŒhrt (zumindest fast, die Wertebereiche der Achsen sind fĂŒr den sichtbaren Bereich noch −1..1, siehe Abschnitt „Window-Viewport-Transformation“).

Beleuchtung

Oft enthĂ€lt eine Szene an verschiedenen Positionen platzierte Lichtquellen, um die Beleuchtung der Objekte realistischer erscheinen zu lassen. In diesem Fall wird fĂŒr jeden Vertex anhand der Lichtquellen und den zum entsprechenden Dreieck gehörenden Materialeigenschaften ein VerstĂ€rkungsfaktor fĂŒr die Textur berechnet. Im spĂ€teren Rasterungsschritt werden die Eckpunktwerte eines Dreiecks ĂŒber dessen FlĂ€che interpoliert. Eine allgemeine Beleuchtung (ambient light) wird auf alle FlĂ€chen angewendet. Es ist die diffuse und damit richtungsunabhĂ€ngige Helligkeit der Szene. Die Sonne ist eine gerichtete Lichtquelle, die als unendlich weit entfernt angenommen werden kann. Die Beleuchtung, die die Sonne auf einer FlĂ€che bewirkt, wird durch Bilden des Skalarproduktes des Richtungsvektors von der Sonne und des Normalvektors der FlĂ€che bestimmt. Ist der Wert negativ, ist die FlĂ€che der Sonne zugewandt.

Clipping

Nur die Primitive, die sich innerhalb des Sichtvolumens befinden, mĂŒssen auch tatsĂ€chlich gerastert werden. Primitiven, die sich vollstĂ€ndig außerhalb des Sichtvolumens befinden, werden verworfen; dies wird Frustum Culling genannt. Weitere Culling-Verfahren wie Backface Culling, die die Zahl der zu berĂŒcksichtigenden Primitiven reduzieren, können theoretisch in einem beliebigen Schritt der Grafikpipeline ausgefĂŒhrt werden. Primitiven, die sich nur teilweise im Innern des WĂŒrfels befinden, mĂŒssen gegen den WĂŒrfel geclippt werden. Der Vorteil des vorherigen Projektionsschrittes liegt darin, dass das Clipping stets gegen den gleichen WĂŒrfel stattfindet. Nur die – eventuell geclippten – Primitiven, die sich innerhalb des Sichtvolumens befinden, werden an den nĂ€chsten Schritt weitergeleitet.

Window-Viewport-Transformation

Um das Bild an einem beliebigen Zielbereich (Viewport) des Bildschirms auszugeben, muss eine weitere Transformation, die Window-Viewport-Transformation, angewandt werden. Dabei handelt es sich um eine Verschiebung, gefolgt von einer Skalierung. Die resultierenden Koordinaten sind die GerĂ€tekoordinaten des AusgabegerĂ€ts. Der Viewport enthĂ€lt 6 Werte: Höhe und Breite des Fensters in Pixeln, die linke, obere Ecke des Fensters in Fensterkoordinaten (meist 0, 0) und die Minimum- und Maximumwerte fĂŒr Z (meist 0 und 1).

Damit ist ( x y z ) = ( v p . X + ( 1.0 + v . X ) ∗ ∗ v p . w i d t h / 2.0 v p . Y + ( 1.0 − − v . Y ) ∗ ∗ v p . h e i g h t / 2.0 v p . m i n z + v . Z ∗ ∗ ( v p . m a x z − − v p . m i n z ) ) {\displaystyle {\begin{pmatrix}x\\y\\z\end{pmatrix}}={\begin{pmatrix}{vp}.X+(1.0+v.X)*{vp}.{width}/2.0\\{vp}.Y+(1.0-v.Y)*{vp}.{height}/2.0\\{vp}.{minz}+v.Z*({vp}.{maxz}-{vp}.{minz})\end{pmatrix}}}
Mit vp=Viewport; v=Punkt nach Projektion

Auf moderner Hardware werden die meisten Schritte der Geometrie-Berechnung im Vertex-Shader durchgefĂŒhrt. Dieser ist im Prinzip frei programmierbar, ĂŒbernimmt aber in der Regel mindestens die Transformation der Punkte und die Beleuchtungsberechnung. FĂŒr die Programmierschnittstelle DirectX ist ab Version 10 der Einsatz eines benutzerdefinierten Vertex-Shaders unumgĂ€nglich, wĂ€hrend Ă€ltere Versionen noch einen Standard-Shader zur VerfĂŒgung gestellt haben.

Rasterung

Im Rasterungsschritt werden alle Primitiven gerastert, es werden also aus kontinuierlichen FlÀchen diskrete Fragmente erstellt.

In dieser Stufe der Grafikpipeline werden zur besseren Unterscheidbarkeit die Rasterpunkte auch Fragmente genannt, d. h. jedes Fragment entspricht einem Pixel im Framebuffer und dieses entspricht einem Pixel des Bildschirms.

Diese können dann eingefĂ€rbt (ggf. beleuchtet) werden. Des Weiteren ist es nötig, bei ĂŒberlappenden Polygonen das jeweils sichtbare, also nĂ€her am Betrachter liegende, zu ermitteln. FĂŒr diese sogenannte Verdeckungsberechnung wird ĂŒblicherweise ein Z-Buffer verwendet. Die Farbe eines Fragments hĂ€ngt von der Beleuchtung, Textur und anderen Materialeigenschaften des sichtbaren Primitivs ab und wird oft anhand der Dreieckseckpunkte interpoliert. Wo vorhanden, wird ein Fragment-Shader im Rasterungsschritt fĂŒr jedes Fragment des Objektes durchlaufen. Sollte ein Fragment sichtbar sein, kann es nun mit bereits vorhandenen Farbwerten im Bild gemischt werden, falls Transparenzen simuliert werden oder Multi-Sampling verwendet wird. In diesem Schritt wird aus einem oder mehreren Fragmenten ein Pixel.

Damit der Anwender nicht die allmÀhliche Rasterung der Primitiven sieht, findet Doppelpufferung statt. Die Rasterung erfolgt dabei in einem besonderen Speicherbereich. Sobald das Bild komplett gerastert wurde, wird es auf einmal in den sichtbaren Bereich des Bildspeichers kopiert.

Inverse

Alle verwendeten Matrizen sind regulĂ€r und damit invertierbar. Da durch die Multiplikation zweier regulĂ€rer Matrizen wieder eine regulĂ€re Matrix entsteht, ist auch die gesamte Transformationsmatrix invertierbar. Die Inverse wird benötigt, um aus Bildschirmkoordinaten wieder Weltkoordinaten zu berechnen – beispielsweise um aus der Mauszeigerposition auf das geklickte Objekt zu schließen. Da aber der Bildschirm und die Maus nur zwei Dimensionen haben, ist die dritte unbekannt. Es wird daher ein Strahl an der Cursorposition in die Welt projiziert und dann der Schnittpunkt dieses Strahles mit den Polygonen in der Welt bestimmt.

Shader

Klassische Grafikkarten orientierten sich im internen Aufbau noch relativ eng an der Grafik-Pipeline. Mit steigenden Anforderungen an die GPU wurden EinschrĂ€nkungen schrittweise aufgehoben, um mehr FlexibilitĂ€t zu schaffen. Moderne Grafikkarten nutzen eine frei programmierbare shadergesteuerte Pipeline, die es erlaubt, direkt in einzelne Bearbeitungsschritte einzugreifen. Um den Hauptprozessor zu entlasten, wurden zusĂ€tzliche Bearbeitungsschritte innerhalb der Pipeline eingefĂŒhrt, die bislang nur auf der CPU liefen.

Die wichtigsten Shadereinheiten sind Pixel-Shader, Vertex-Shader und Geometrie-Shader. Um alle Einheiten optimal auszunutzen, wurde der Unified-Shader eingefĂŒhrt. Dadurch gibt es nur noch einen einheitlichen großen Pool von Shader-Einheiten. Je nach Bedarf wird der Pool in unterschiedlichen Gruppen von Shadern aufgeteilt. Eine strikte Trennung zwischen den Shader-Typen ist daher nicht mehr sinnvoll. Inzwischen ist es auch möglich, ĂŒber einen sogenannten Compute-Shader beliebige Berechnungen abseits der Darstellung von einer Grafik auf der GPU ausfĂŒhren zu lassen. Der Vorteil liegt darin, dass diese stark parallelisiert laufen, es gibt dabei jedoch EinschrĂ€nkungen. Diese universellen Berechnungen werden auch GPGPU genannt.

Literatur

‱ Tomas Akenine-Möller, Eric Haines: Real-Time Rendering. AK Peters, Natick MA 2002, ISBN 1-56881-182-9.
‱ Michael Bender, Manfred Brill: Computergrafik: ein anwendungsorientiertes Lehrbuch. Hanser, MĂŒnchen 2006, ISBN 3-446-40434-1.
‱ Martin Fischer: Pixel-Fabrik. Wie Grafikchips Spielewelten auf den Schirm zaubern. In: c’t Magazin fĂŒr Computer Technik. Heise Zeitschriften Verlag, 4. Juli 2011, S. 180.

Einzelnachweise

cite-note-11. ↑ Tomas Akenine-Möller, Eric Haines: Real-Time Rendering. S. 11.
cite-note-22. ↑ K. Nipp, D. Stoffer; Lineare Algebra; v/d/f Hochschulverlag der ETH ZĂŒrich; ZĂŒrich 1998, ISBN 3-7281-2649-7.